Elementary Strong Functional Programming

Functional programming is a good idea, but we haven’t got it quite right yet. What we have been doing up to now is weak (or partial) functional programming. What we should be doing is strong (or total) functional programming in which all computations terminate. We propose an elementary discipline of strong functional programming. A key feature of the discipline is that we introduce a type distinction between data, which is known to be finite, and codata, which is (potentially) infinite. 1 What is Functional Programming? It is widely agreed that functional programming languages make excellent introductory teaching vehicles for the basic concepts of computing. The wide range of topics covered in this symposium is evidence for that. But what is functional programming? Well, it is programming with functions, that much seems clear. But this really is not specific enough. The methods of denotational semantics show us how almost any programming language construction, no matter how opaque and side-effect ridden, can be construed functionally if we are willing to introduce complicated enough spaces for the functions to work on. It is somewhat difficult to pin down with complete precision, but what we conventionally mean by functional programming involves the idea that the functions are transparent in the notation we actually write, rather than having to be teased out by some complex process of interpretation. For example if I write, in Miranda or Haskell (actually neither language has nat as a distinct type, but that’s an oversight) > fac :: nat->nat > fac 0 = 1 > fac (n+1) = (n+1) * fac n then the semantics I intend has that fac really is a function from natural numbers to natural numbers, not something else, such as a function from nat×store